把估算轉化為實測資料

在大型語言模型（LLM）落地私有地端（On-Premise）的架構中，推論服務冷啟動（Cold Start）與模型權重載入速度是維運的核心指標之一。

在先前的架構規劃中，曾推估在 10GbE 網路環境下載入約 63.4 GB 的開源大模型冷啟動需要約 60 秒，並在掛載參數中設定了 nconnect=4。然而，這個 4 到底是不是最佳配置？模型權重究竟該走 NFS 集中管理，還是切 iSCSI 甚至放本機？

今天來把測試工具與標準方法確定好，將先前的理論推估替換為實測資料，同時探討 NAS 儲存池的 RAID 拓撲選擇，因為在實際架構中，載入時間的物理上限往往是由 NAS 的磁碟陣列吞吐量所決定。

這邊先揭露實測結論：

1. 理論估算破滅：原先預估的 60 秒並不成立。在四碟 RAIDZ1 儲存池上，實際載入耗時約 106 至 110 秒，真正的效能瓶頸在底層磁碟陣列，調整 nconnect（從 1 到 8）完全沒有帶來效能提升。
2. 三項被忽視的關鍵變因：
   • NFS readahead：客戶端預設值讓 mmap 類型的載入器速度慢了將近一倍。
   • 系統長時間運行的衰退：特定 NAS 連續運行多日後循序讀取效能下降了 3.5 倍，重啟後才恢復正常。
   • 底層 SSD 快取干擾：NAS 系統層透明快取會讓量測資料失真，誤把快取命中當成真實硬碟效能。

一、三條儲存路徑的定位與假設

為了釐清不同儲存路徑對推論服務的影響，這次針對以下三條 AI 算力節點需要用到的儲存路徑進行對比：

說明：iSCSI 的定位

iSCSI LUN 屬於單一 Initiator 的區塊設備，多個節點無法在沒有叢集檔案系統的前提下同時掛載讀寫。因此它無法替代 NFS 作為集中模型庫，但可以作為本機磁碟容量不足時的延伸選項。

頻寬與硬體極限推算

• 本機 NVMe：在將系統 readahead 調整至 8 MB 後，循序讀取基準速度可達約 5.2 GiB/s。
• 10GbE 網路：理論線速 1.25 GB/s，扣除封包負載後以 85% 計算約為 1.06 GB/s。
• 四碟 NAS RAIDZ1 儲存池：單顆企業級硬碟循序讀取約 200 至 250 MB/s。4 碟 RAIDZ1 讀取吞吐近似 3 顆資料碟累加，約 600 至 750 MB/s。

此數值明顯低於 10GbE 頻寬上限，意味著 NFS 的瓶頸在於 NAS 磁碟組而非網路本身。

測試環境與平台說明

測試使用三種不同儲存池結構的 NAS 環境進行對照：

• 作業系統：NAS 均採用 ZFS 底層系統（QuTS hero），網路均為 10GbE 連線。
• 測試資料：
  1. gpt-oss-120b safetensors 格式（15 個檔案，共計 65.28 GB / 60.79 GiB）。
  2. 量化 GGUF 模型檔（約 63.4 GB）。
  3. 全部檔案均與原始校驗碼（SHA-256）比對無誤。
• 節點配置：量測時暫停推論服務，確保 GPU 運算節點具備超過 100 GiB 以上之未占用記憶體。

二、儲存效能量測的四大陷阱

在進行效能基準測試時，若忽視底層快取機制，量測資料往往毫無參考價值。

陷阱 1：客戶端快取 vs 伺服器快取 vs 隱藏快取層

在 Linux 客戶端執行 echo 3 > /proc/sys/vm/drop_caches 只能清空節點本機的 Page Cache，無法清空 NAS 端的 ZFS ARC（Adaptive Replacement Cache）。因此：

• 第一次冷讀取後，第二次測試看似「冷啟動」，實際上資料已全部駐留在 NAS 的記憶體快取中。
• 對策：量測客戶端時必須透過 zpool iostat 同步監看 NAS 端硬碟是否有實際 I/O 發生。

此外，儲存系統的透明快取層更具隱蔽性。例如單碟測試機量測 60 GiB 資料時，連續跑出 0.47 GiB/s 的異常高速，深入檢查 /proc/diskstats 後才發現，資料全部被讀取快取專用的 SSD 攔截處理，磁碟本體幾乎無 I/O，所以測試前，務必確認儲存池是否掛載了 Cache 設備。

陷阱 2：readahead 與 nconnect 的設定交互

• nconnect 的特性：同一個 NAS 伺服器在客戶端僅有「第一個掛載點」所指定的 nconnect 會生效。後續掛載若未重新建立連線，設定值將被忽略。量測時需以 ss -tn 核對實際建立的 TCP 連線數。
• readahead 的決定性影響：
  • 區塊設備 readahead 位於 /sys/block/<dev>/queue/read_ahead_kb。
  • NFS 掛載點 readahead 則由 /sys/class/bdi/<Major:Minor>/read_ahead_kb 控制，核心預設僅 128 KB。
  • 實測發現，循序讀取受 128 KB 影響較小，但對於以 mmap 機制運作的載入器，128 KB 耗時高達 197 秒，調大至 15 MB 則大幅縮短至 114 秒。

陷阱 3：權重讀取模式決定硬體瓶頸

不同推論框架對權重檔的載入機制完全不同：

• safetensors / vLLM：採用大區塊循序讀取。
• GGUF / llama.cpp：預設採用記憶體映射（mmap）逐頁存取。

這兩種模式對儲存架構帶來的壓力差異巨大，測試工具必須針對循序讀取（readinto）與映射存取（mmap）分別量測。

陷阱 4：儲存系統長時間運行後的效能劣化

在進行基準測試時，初測 65 GB 模型透過 NFS 耗時高達 500 秒以上，在 NAS 本機直接讀取亦需 512 秒。觀察 I/O 發現每次讀取區塊極度破碎（僅約 64 KB）。將開機超過五天跑很多服務可能造成一些影響的 NAS 重啟後，相同測試透過 NFS 縮短至 158 秒，本機讀取恢復至 105 秒。在進行任何正式測試前，記錄設備的 Uptime 是必要的驗證步驟。

三、量測工具設計：spb.py

為了消除上述陷阱，設計了輕量化量測工具 spb.py（使用 Python 標準函式庫），重點在於完整記錄量測當下的環境條件。

# 循序讀取測試（清除本機快取，量測 3 輪）
python3 spb.py run --path "/srv/models/llm/<model-path>" --label nfs-cold --rounds 3 --drop-caches

# 記憶體映射模式測試
python3 spb.py run --path "/srv/models/gguf/<model-path>" --label nfs-mmap --mode mmap

# 產出彙整報告
python3 spb.py report results.jsonl

工具的核心機制

1. 結構化記錄（JSONL）：每次測試完整記錄時間戳記、模式、總位元組數、耗時、吞吐量（GiB/s）、本機快取狀態、系統負載與掛載參數。
2. 網路與連線驗證：NFS 掛載點自動解析底層實際連線數（TCP connections）、專屬 read_ahead_kb 以及實體網卡交涉速率（避免 10GbE 降速至 2.5GbE/1GbE 卻未被察覺）。
3. 無 Root 權限支援：若無 root 權限清除快取，改採 posix_fadvise(POSIX_FADV_DONTNEED) 對指定檔案進行精準快取釋放。

四、NAS 的 RAID 拓撲抉擇：容量與容錯權衡

儲存載入的上限有一半取決於 NAS 磁碟組的配置。磁碟陣列一旦建立，日後變更需要龐大的搬遷成本。

如果以市面上主流的 4 槽機種（4 顆 8TB）與大型 16 槽機架式儲存設備（16 顆 18TB）為例，計算實體容量與可用空間：

容量計算備註

• 「扣除 9%」源自 ZFS 的 Allocation Slop Space、RAIDZ Padding 與系統保留空間，實機與理論公式會有約 9.1% 的固定落差。
• 80% 安全線：ZFS 使用率超過 80% 後效能將明顯下滑，因此規劃可用容量時應以 80% 為上限基準。

選擇策略分析

1. 4 槽機種：首選 RAIDZ1

   若預估模型庫初期需求約 2 至 4 TB，4顆硬碟組 RAIDZ1 或 RAID5 的可用空間相當充裕。若選 RAIDZ2 會損失高達 50% 原始容量，代價過高。重建風險需透過異地冷備份機制來承擔。

2. 16 槽機種：首選 RAID 60（雙 RAIDZ2 群組）

   18TB 大容量硬碟重建需耗時超過 30 小時。如果採用「單一 16 碟寬 RAIDZ2」，重建時必須同時讀取其餘 15 顆硬碟，期間若再損壞 2 顆即全池損毀，改採 RAID 60（拆分為兩組 8 碟 RAIDZ2），重建僅需同組的 7 顆硬碟參與 I/O，大幅縮小損壞風險範圍。

五、完整實測資料

以下測試資料量均為 65.28 GB，冷讀取狀態均透過 NAS 端 zpool iostat 確認真實磁碟讀取量，取多次量測之中位數。

1. 四碟 RAIDZ1 測試

資料洞察：

• 原先預估的 60 秒落空，實際需要 106 至 110 秒。在磁碟成為瓶頸時，調整 nconnect 毫無效果。
• iSCSI 是否優於 NFS？ 答案取決於 LUN 建立時的磁區大小（Block Size）。預設 8K 表現落後，調大至 128K 後能減少中繼資料開銷，時間縮短至 88 秒。但此參數在建立 LUN 後無法動態調整。

2. 模型庫測試（長時間運作與重開對比）

3. 推論引擎真實載入實測（65GB 模型）

在相同運算節點上，分別透過 llama.cpp 與 vLLM（v0.30.0）實際載入 65GB 模型：

推論引擎的關鍵特性：

1. llama.cpp：
   • 走 NFS 時，若使用預設的 mmap 需要 219 秒，停用 mmap 改走循序讀取（--load-mode none，舊版參數為 --no-mmap），時間立即降至 123 秒，省下近 100 秒的開銷。
2. vLLM：
   • 載入時間與儲存路徑幾乎脫鉤。即便在 5 GiB/s 的本機 NVMe 上，載入權重仍需 7 分鐘以上。vLLM 的瓶頸主要卡在 CPU/GPU 處理權重轉換與張量初始化的運算階段，儲存端並非主要阻塞點。

六、實作指南：如何重現與配置最佳化

1. 執行路徑基準量測

# 取得測試腳本
git clone "https://github.com/ivanusto/storage-path-bench" && cd storage-path-bench

MODEL_PATH="/srv/models/llm/<your-model-dir>"

# 執行冷讀取測試
python3 spb.py run --path "$MODEL_PATH" --label nfs-cold-4 --rounds 3 --drop-caches

# 執行熱快取讀取測試
python3 spb.py run --path "$MODEL_PATH" --label nfs-warm --rounds 2

# 產出彙整資料
python3 spb.py report results.jsonl

2. NFS 最佳化掛載與參數校調

# 卸載並使用指定參數重新掛載
sudo umount /srv/models
sudo mount -t nfs4 -o ro,vers=4.1,hard,noatime,nconnect=8,rsize=1048576 "<NAS_IP>:/models" /srv/models

# 驗證實際 TCP 連線數是否為 8
ss -tn 'dst <NAS_IP>:2049' | tail -n +2 | wc -l

# 檢視目前掛載點的 readahead（預設通常為 128 KB）
cat /sys/class/bdi/$(mountpoint -d /srv/models)/read_ahead_kb

# 提高 NFS 掛載點 readahead 至 15 MB
echo 15360 | sudo tee /sys/class/bdi/$(mountpoint -d /srv/models)/read_ahead_kb

提示：NFS 掛載點的 read_ahead_kb 在每次重新掛載後會重設為預設值，建議建立 systemd service 或 udev 規則在開機時自動套用。

3. NAS 端磁碟讀取極限檢測

在 NAS 上直接排查磁碟吞吐，避免網路層干擾：

# 在 NAS 本機進行磁碟循序讀取
cd "/share/models/llm/<your-model-dir>"
time sh -c 'for f in model-*.safetensors; do dd if="$f" of=/dev/null bs=8M; done'

# 開啟另一個終端機監控 ZFS 磁碟狀態與讀取量
zpool iostat -v 5

七、結論與規劃更新

依據本次實測結果，針對 65GB 規模的大語言模型冷啟動規劃，我後來做了調整，之後就多是以這個版本進行實作囉：

1. 儲存頻寬邊界：四碟 RAIDZ1 儲存池的實體極限約為 100 秒，這決定了 NFS 載入的物理下限。
2. 推論框架選擇：
   • 使用 llama.cpp 時，透過 NFS 務必加入 --load-mode none，將載入時間從 3.7 分鐘壓回 2 分鐘邊界。
   • 使用 vLLM 時，無須過度糾結儲存協定，7 至 8 分鐘的初始化瓶頸在於計算與張量重建。
3. iSCSI 規劃策略：僅在配置大區塊（128K 以上）LUN 時具備效能優勢，若為預設小區塊，效能反而不如經過最佳化的 NFS。

參考資源

• OpenZFS Documentation：RAIDZ Pool Configuration & Space Allocation
• Linux Kernel NFS Mount Documentation：nfs(5) man page
• Linux Page Cache Management：Documentation/sysctl/vm.txt
• QNAP ZFS RAID 計算工具 ：QNAP RAID 計算器